Program development suport device, program execution device, compile method and debug method

ABSTRACT

On a program development apparatus (workstation, for example), a description of a specific language source program (ATL, for example) is embedded into a preprocessor description of a general-purpose language source program (C language, for example) to create a mixed language source program. The general-purpose language source program description and the specific language source program description are extracted from the mixed language source program, compiled by respective compilers, and the respective object codes thus obtained are combined to form one object file.

TECHNICAL FIELD

The present invention relates to a program development supportingapparatus for developing a specific language program that includes adescription of a control command for a device under test such as asemiconductor device and a general-purpose language (GPL) program thatincludes a description on steps such as an execution step of thespecific language program and a processing step of data obtained fromthe specific language program, a program executing apparatus forexecuting the programs, a compiling method of the programs and adebugging method of the programs. In particular, the present inventionrelates to a program development supporting apparatus, a programexecuting apparatus, a compiling method and a debugging method fordeveloping a mixed language program where a specific language programand a general-purpose language program are mixed and described in onefile.

BACKGROUND ART

Many electronic devices such as measuring devices and communicationdevices, which are required to process a large volume of various typesof signals, are provided with a high-performance processor. A program(firmware) to be performed on the processor tends to be complicated andlarge in size. The program recorded in the electric devices oftenincludes unknown bugs. Further, customers often request addition orimprovement of functions of the-devices.

In order to deal with these requirements, many electronic devices aremade connectable with external computers via a communication cable whichallows updating of the program and setting/monitoring of the operation.In other words, a control command or a control program itself can bedistributed from an external computer to the processor of such anelectronic device. Further, program algorithm and setting may bedeveloped on the external computer to be operated on such an electronicdevice.

Among such electronic devices, a semiconductor test equipment isparticularly unique since the semiconductor test equipment needs tooperate on a wide variety of special-purpose semiconductor devices eachof which needs to be tested with a specific device testing program. Inrecent years, it has become common that the user of the semiconductortest equipments, i.e., the semiconductor device manufacturer, develop aprogram executed on the processor of the semiconductor test equipment byhimself.

However, most of the processors which are used in the special-purposeelectronic devices, in particular, the semiconductor test equipments,tend to mount specific processors which can process only the binaryfiles that comply with the specific specification. Then, a source file,which is used as a basis for such binary files, also has to be createdaccording to a specific specification of the programming language andthe development support environment, which, in turn, requires theprogram developers to be skilled not only in the programming languagebut also in the operation of specific development supportingenvironments.

In view of the above, some electronic devices are proposed which arecapable of executing a program developed in the general-purpose languagesuch as C language or JAVA (registered trademark). In such devices,however, program resources developed according to the specificspecification cannot be utilized.

One conventional technique to eliminate such inconvenience is todescribe entire data process and algorithm in general-purpose languagesuch as C language and to call a program described in a languagespecific to each electronic device as a subroutine. An example ofprogram development and execution according to this technique isdescribed in detail below, where the electronic device that executes theprogram is assumed to be a semiconductor test equipment.

To facilitate the understanding of a program executing operation on thesemiconductor test equipment, the semiconductor test equipment and theprogram development environment thereof are described. The semiconductortest equipment is a special measuring device that conducts apredetermined operation test on semiconductor devices such as asemiconductor memory device, a logic IC, a linear IC, and the devicestructure varies according to the types of semiconductor devices to betested. Generally, a workstation is connected to the semiconductor testequipment to give a test execution direction to the semiconductor testequipment, to acquire test results, and to develop a program. Thesemiconductor test is realized with a semiconductor testing systemconsisting of a semiconductor test equipment and a workstation asdisclosed in Japanese Patent Laid-Open No. 2001-195275 Publication.

FIG. 10 is a block diagram of an overall structure of a conventionalsemiconductor testing system, in which a structure common to differentsemiconductor test equipments for different device tests is shown. InFIG. 10, a semiconductor test equipment 100 includes a tester processor110, a main tester unit 120, a tester head 130, and a communicationinterface 140.

The tester processor 110 serves to transmit a control command and toreceive/transmit a test data to/from the main tester unit 120, andfunctions as a controller that controls the main tester unit 120 andcommunication with a workstation which will be described later.Specifically, the tester processor 110 includes an Operating System (OS)kernel 111 in an embedded memory (not shown) to perform a set-up and amonitoring of a device testing program, a memory management, as well asa monitoring/control of the communication interface 140, a control ofthe main tester unit 120, and the transmission of the test data, via acommunication bus driver 112 and a tester bus driver 113 similarlystored in the memory.

The device testing program is configured with a general-purpose languageprogram 114 and a specific language program 117 as described above,which as a whole define the procedure for executing various tests, suchas a function test, and a DC parametric test, for a tested device 131.The general-purpose language program 114 is configured with a statementwhich includes a processing command for various data obtained as aresult of test, and a statement which includes a command that indicateshow to execute the entire device testing program, and is a binary filewhich is directly executable on the OS kernel 111.

On the other hand, the specific language program 117 is an object filewhich is configured with a command to control the main tester unit 120.The object file, similarly to the specific language program which is aninherited resource, is a binary file that is directly executable only ona kernel optimized for the specific language program 117. Hence, whenthe specific language program 117 is to be executed on the OS kernel111, an execution emulator 115 has to perform an interpretation process.In addition, the specific language program 117 further includes aninput/output command related with operations such as a disc access,keyboard input, monitor display, for a workstation 200 as describedlater. For the execution of such input/output command, in addition tothe interpretation by the execution emulator 115, an interpretation byan IO control emulator 116 is required.

The main tester unit 120 serves to perform various tests, such as afunction test, a DC parametric test, and an RF test (high harmonic test)on the tested device 131, which is mounted on the test head 130,according to the control command sent from the tester processor 110, andis provided with a register 121, a memory 122, and a test signalreceiving/transmitting unit 123. The register 121 stores various datatransmitted from the tester bus driver 113 in the tester processor 110.The stored data is in turn transmitted to the test signalreceiving/transmitting unit 123 directly or via the memory 122.

Then, the test signal receiving/transmitting unit 123 outputs the datato be temporarily stored in the register 121 or the memory 122, and thento be transmitted to the tester bus driver 113 in the tester processor110 via the register 121. The test signal receiving/transmitting unit123 being configured with various test units such as a patterngenerator, a timing generator, and a DC unit, outputs test signalsgenerated by the test units and obtains data appear on an output pin ofthe tested device 131.

FIG. 11 is a block diagram of an overall structure of the workstation200. The workstation 200 serves as a console terminal that transfers aprogram and gives an execution direction to the tester processor 110 inthe semiconductor test equipment 100 as well as a program developmentsupporting apparatus that supports the development of thegeneral-purpose language program 114 and the specific language program117. In FIG. 11, the workstation 200 includes a processor 220, acommunication interface 241, a hard disc 242, a mouse 243, a keyboard244, and a display 245.

The processor 220 includes an Operating System (OS) kernel 221 in anembedded memory (not shown), and performs processing such as set-up andmonitoring of various programs, a memory management, monitoring andcontrol of the communication interface 241, read-out/write-in of programand data from/to the hard disc drive 242, acquisition of informationinput from the mouse 243 and the keyboard 242, an output of displayinformation to the display 245 via units that are similarly stored inthe memory, such as a communication bus driver 223, a hard disc driver224, a mouse driver 225, a keyboard driver 226, and a display driver227. Here, the communication interface 241 is connected to thecommunication interface 140 shown in FIG. 10 via a communication cable(not shown) to allow the communication between the workstation 200 andthe semiconductor test equipment 100.

Further, the OS kernel 221 includes a Graphical User Interface (GUI)processing unit 222. Various programs such as an editor 228, ageneral-purpose language compiler 229, a linker 233, a general-purposelanguage debugger 231, a specific language compiler 230, and a specificlanguage debugger 232 can be executed on separate window screensdisplayed on the display 245. The workstation 200 is equivalent inconfiguration to a general computer. The various drivers and programsmentioned above are generally stored in the hard disc drive 242 to beread out and executed according to the OS kernel 221 as necessary.

Described next is the procedure of the development and the execution ofthe device testing program in the semiconductor testing systemconsisting of the semiconductor test equipment 100 and the workstation200. FIG. 12 is a flowchart of a procedure of development and executionof a conventional device testing program. Here, the device testingprogram is configured with the general-purpose language program and thespecific language program as described above. As an example, C languageis adapted as the general-purpose language program and ATL (standardspecific to Advantest Co.) is adapted as the specific language program.

First, the program developer starts up the editor 228 on the workstation200 to create a source program in C language (at step S301). The sourceprogram describes an algorithm of the entire device testing program asdescribed above, and defines procedure to call and execute the objectprogram described in ATL and to process test result data obtained as aresult of the execution.

After the creation of the source program in C language, the programdeveloper designates a file of the created source program (hereinafterreferred to as C source file including a necessary header file or thelike) to a C compiler (corresponding to the general-purpose languagecompiler 229) to execute a compiling (at step S302). In the compilingprocess, a syntax checking is first performed. When a syntax error isfound, the program developer corrects the error with the editor 228 anddesignates the execution of compile again. When no error is found, anobject file, which is a translation of the C source file into a machinelanguage (referred to as C object file hereinafter), is created.

After the completion of step S302, the program developer designatesnecessary library files for the created C, object files and makes thelinker 233 execute the link for the C source files created at step S301(at step 303). With the linking process, a single C object file iscreated which is directly executable on the tester processor 110 of thesemiconductor test equipment 100.

Further, the program developer starts up the editor 228 on theworkstation 200 to create a source program in ATL (at step S401) inparallel with the creation of the object files in C language. The sourceprogram, as described above, describes a control command for controllingthe semiconductor test equipment 100.

After the completion of source program creation in ATL, the programdeveloper designates a created source program file (referred to as ATLsource file hereinafter) and makes an ATL compiler (corresponding to thespecific language compiler 230) execute the compile (at step S402).Similarly to step S302 described above, in the compiling process, thesyntax checking is first performed. When the syntax error is found theprogram developer corrects the error with the editor 228 and designatesthe execution of compile again. When no error is found, the ATL sourceprogram described above is translated into a machine language of an oldtester processor which is different from the machine language used inthe C object file, in other words, a machine language understandable toa specific tester processor, and an object file (referred to as ATLobject file hereinafter) is created.

When the single C object file and the ATL object file group are preparedaccording to such procedure, the program developer starts up a controlprogram to enable the communication with the semiconductor testequipment 100 on the workstation 200, and with the use of the started-upcontrol program, transfers the single C object file and the ATL objectfile group to the tester processor 110 of the semiconductor testequipment 100 (at steps S304 and S403).

Then, the program developer designates the execution of the single Cobject file to the control program (at step S305). Then, according tothe algorithm described in the single C object file, the testerprocessor 110 of the semiconductor test equipment 100 repeats theprocessing cycle starting from the execution of the ATL object file, theoperation of a desired test unit in the main tester unit 120,acquisition of test result obtained from the tested device 131, up todata processing. Here, the test result to which appropriate dataprocessing is conducted can be received according to the control programmentioned above via the communication interface 140 of the semiconductortest equipment 100, the communication cable, and the communicationinterface 241 of the semiconductor test equipment 100, and displayed ona window screen designated to the control program.

On finding inconvenience such as obvious error in test results, theprogram developer determines that the device testing program includes alogical error. Then the program developer starts up the general-purposelanguage debugger 231 on the workstation 200 to set a breakpoint in apredetermined statement in the C source file. When the program developerorders to start debugging, the general-purpose language debugger 231executes the single C object file according to the procedure of stepsS302 to S305 again. When it is detected that the process reaches the setbreakpoint in the statement, a valid variable up to the breakpoint isdisplayed. The program developer, upon finding a logical error throughthe checking of the valid variable, starts up the editor 228 to correctthe C source file as necessary and repeats the procedure of the stepsS302 to S305 as described above.

On the other hand, when the general-purpose language debugger 231 doesnot find a logical error in the C source file, the program developerproceeds to start up the specific language debugger 232 to set abreakpoint in a predetermined statement in the ATL source file and toperform a debugging process as above.

As described earlier, however, when the program to be executed on thetested device (the semiconductor test equipment in the example here) isdescribed in different languages such as the general-purpose languageand the specific language, though the utilization of the past programresource written in the specific language is allowed, different sourcefiles are necessary in the development stage of the programs. In theabove example, two different files need to be prepared as the C sourcefile and the ATL source file. In brief, when the source file written inthe general-purpose language includes a call of the object file writtenin the specific language, at least two source files are necessary. Inparticular, one general-purpose language source file needs to be managedin combination with corresponding specific language source file, sinceone general-purpose language source file corresponds with a specificlanguage source file.

Further, identification of associated source files written in differentlanguages based on the contents of the source files is difficult. Hence,mismanagement of the source files may cause wastes of time and energyfor the relocating of source file association. Thus, the correction andpartial citation of source files on the editor must be conducted with atmost caution. Such inconvenience also contributes to increase the numberof errors made by the program developer.

Still further, since both general-purpose language source file and thespecific language source file are required to be prepared for oneexecution program, same number of object files are created as a resultof compiling thereof. This means further complication in the management.Thus, conventionally source files and object files in differentlanguages exist per one execution program, which complicates the filemanagement and degrades the development efficiency of the program.

In view of the foregoing, an object of the present invention is toprovide a program development supporting apparatus, a program executingapparatus, a compiling method and a debugging method which, through anembedding of a source file written in a specific language into apreprocessor description of a general-purpose language source file,allow a significant reduction in the number of necessary source filesand object files per one execution file, and a utilization of pastresource written in the specific language.

DISCLOSURE OF INVENTION

To achieve an object as described above, a program developmentsupporting apparatus according to the present invention is forgenerating a program file executable on a predetermined programexecuting apparatus from a mixed language source program where aspecific language source program is described in a predetermined area ofa general-purpose source program, and includes a specific languagecompiling unit (corresponding to a specific language compiler 30described later) that compiles the specific language source program tocreate a specific language object code; a general-purpose languagecompiling unit (a general-purpose language compiler 29 as describedlater) that compiles the general-purpose language source program tocreate a general-purpose language object code; an integrated compilingunit (corresponding to an integrative compiler 34 as described later)that extracts the specific language source program from the mixedlanguage source program, designates the extracted specific languagesource to the specific language compiling unit to execute, designate themixed language source program to the general-purpose language compilingunit to execute, integrates the obtained specific language object codeand the general-purpose language object code to create an object file;and a linking unit (corresponding to a linker 33 as described later)that create the program file from at least one object file created bythe integrated compiling unit.

Further, a program executing apparatus (corresponding to a semiconductortest equipment 11 described later) according to the present inventionexecutes a program file where an object code of a general-purposelanguage source program and an object code of a specific language sourceprogram are present in a mixed manner, and the object code of thegeneral-purpose language source program and the object code of thespecific language source program are loaded on a memory when anexecution of the program file starts.

Still further, a compiling method according to the present invention isfor generating a program file executable on a predetermined programexecuting apparatus from a mixed language source program where aspecific language source program is described in a predetermined area ofa general-purpose language source program, and includes a specificlanguage source program extraction step (corresponding to step S121described later) of extracting the specific language source program fromthe mixed language source program; a specific language compiling step(corresponding to step S123 described later) of compiling the extractedspecific language source program to create a specific language objectcode; a general-purpose language compiling step (corresponding to stepS122 described later) compiling a description of the general-purposelanguage source program from the mixed language source program to createa general-purpose language object code; an object file creationstep(corresponding to step S124 described later) of combining thespecific language object code and the general-purpose language objectcode to create an object file; and a linking step(corresponding to stepS130 described later) of creating the program file from at least oneobject file created by the object file creation.

Still further, a debugging method according to the present invention isa debugging method for debugging a program file executable on apredetermined program executing apparatus created from a mixed languagesource program where a specific language source program is described ina predetermined area of a general-purpose language source program, andincludes a breakpoint setting step of setting a breakpoint in astatement in the mixed language source program; a debugger starting upstep of stopping the program file at the breakpoint during execution ofthe program file, starting up a general-purpose language debugger whenthe statement of the stopped program file belongs to the general-purposelanguage source program (corresponding to step S203 described later),and starting up a specific language debugger when the statement of thestopped program file belongs to the specific language source program(corresponding to step S206 described later); and a debug informationdisplay step of displaying on a common window screen debug information(corresponding to step S205 described later) obtained from thegeneral-purpose language debugger and the specific language debugger(corresponding to steps S204 and S207 described later).

Further, a computer readable recording medium according to the presentinvention is characterized in that the compiling method is executed by acomputer.

Further, a computer readable recording medium according to the presentinvention is characterized in that the debugging method is executed by acomputer.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of an overall structure of a semiconductortesting system according to an embodiment;

FIG. 2 is a flowchart of a procedure of development and execution of adevice testing program;

FIG. 3 is an example of description by a C+ATL source program;

FIG. 4 is a flowchart of compiling process by an integrative compiler;

FIG. 5 is an explanatory diagram of a process of an ATL source filecreation;

FIG. 6 is a diagram of a configuration of a C+ATL object file;

FIG. 7 is a flowchart of a debugger selecting routine;

FIG. 8 is an example of an execution screen of an integrative debuggerwhen a break occurs in an ATL description;

FIG. 9 is an example of an execution screen of an integrative debuggerwhen a break occurs in a C language description;

FIG. 10 is a block diagram of an overall structure of a conventionalsemiconductor testing system;

FIG. 11 is a block diagram of an overall structure of a workstation in aconventional semiconductor testing system; and

FIG. 12 is a flowchart of a procedure of development and execution of aconventional device testing program.

BEST MODE(S) FOR CARRYING OUT THE INVENTION

In the following, an exemplary embodiment of a program developmentsupporting apparatus, a program executing apparatus, a compiling methodand a debugging method according to the present invention will bedescribed in detail with reference to the accompanying drawings. Theembodiment is not intended to limit the present invention.

To facilitate the understanding of features of the present invention, inan embodiment, the present invention is applied to a semiconductortesting system which is configured with a semiconductor test equipmentand a workstation similarly to the conventional technique as describedabove. Specifically, the program development supporting apparatusaccording to the present invention corresponds to the workstation in thesemiconductor testing system, the program executing apparatus accordingto the present invention corresponds to the semiconductor test equipmentin the semiconductor testing system, and the compiling method and thedebugging method according to the present invention correspond to thecompiling method and the debugging method performed on the semiconductortesting system.

FIG. 1 is a block diagram of a semiconductor testing system according tothe embodiment. The semiconductor testing system shown in FIG. 1includes a workstation 10 and a semiconductor test equipment 11,connected via a communication cable with each other.

The basic structure of the workstation 10 is same with the structure ofthe workstation 200 of the conventional semiconductor testing system,and a processor 20, a communication interface 41, a hard disc drive 42,a mouse 43, a keyboard 44, and a display 45 shown in FIG. 1 correspondto the processor 20, the communication interface 41, the hard disc drive42, the mouse 43, the keyboard 44, and the display 45 shown in FIG. 11,respectively.

Similarly, units stored in a memory (not shown) in the processor 20 suchas an OS kernel 21, a GUI processing unit 22, a communication bus driver23, a hard disc driver 24, a mouse driver 25, a keyboard driver 26, adisplay driver 27, an editor 28, a general-purpose language compiler 29,a specific language compiler 30, a general-purpose language debugger 31,a specific language debugger 32, and a linker 33 correspond to the OSkernel 221, the GUI processing unit 222, the communication bus driver223, the hard disc driver 224, the mouse driver 225, the keyboard driver226, the display driver 227, the editor 228, the general-purposelanguage compiler 229, the specific language compiler 230, thegeneral-purpose language debugger 231, the specific language debugger232, and the linker 233 shown in FIG. 11, respectively.

The workstation 10 according to the embodiment differs from theconventional workstation 200 in that the workstation 10 includes anintegrative compiler 34 as an upper level application of thegeneral-purpose language compiler 29 and the specific language compiler30. In other words, the workstation 10 can utilize the general-purposelanguage compiler 29 and the specific language compiler 30 via theintegrative compiler 34.

Further, the workstation 10 according to the embodiment differs from theconventional workstation 200 in that the workstation 10 includes anintegrative debugger 35 as an upper level application of thegeneral-purpose language debugger 31 and the specific language debugger32. The workstation 10 can utilize the general-purpose language debugger31 and the specific language debugger 32 via the integrative debugger 35in a similar manner with the integrative compiler 34.

The semiconductor test equipment 11 is shown to be connected to theworkstation 10 in the semiconductor testing system of FIG. 1, and theinternal structure of the semiconductor test equipment 11 is same withthe conventional semiconductor test equipment 100 shown in FIG. 10. Inthe semiconductor test equipment 11, however, the tester processoroperates partially differently from the conventional processor dependingon a type of a program to be developed in the workstation 10.

A procedure of development and execution of a device testing program inthe semiconductor testing system is described. FIG. 2 is a flowchart ofa procedure of the development and the execution of the device testingprogram according to the embodiment. Similarly to the description ofFIG. 12, in an example shown in FIG. 2, the device testing program isconfigured with the general-purpose language program and the specificlanguage program, and C language is adapted as the general-purposelanguage program and ATL (standard specific to Advantest Co.) is adaptedas the specific language program.

First, the program developer starts up the editor 28 on the workstation10 to create a source program (at step S110). The source program writtenin the C language which is the general-purpose language includes in apreprocessor description the content of ATL source file written in thespecific language, unlike the content of C source file of FIG. 12. Suchsource program is referred to as a C+ATL source program.

FIG. 3 shows an example of the C+ATL source program description. Adescription of “number:” at the left end of the description in FIG. 3 isa row number used for descriptive purpose and ignored in the actualprogram operation. In the following description of the content of theC+ATL source program, each statement will be referred to with the rownumber.

The C language compiler recognizes a statement starting from # as apreprocessor command. In the C+ATL source program shown in FIG. 3,“#include” with row number 1, “#pragma” with row numbers 3, 4, and 5 arethe preprocessor commands. The command “#include” is a command to simplyexpand the content of description of a header file “AT/hybrid.h” at theposition, and the content of the command is necessary for a mainfunction starting from the row number 10.

On the other hand, “#pragma” is a special preprocessor command torealize a unique function of the machine or the OS while maintaining theoverall compatibility with the C language. Hence, by definition,“#pragma” is unique to the machine or the OS and generally different foreach compiler. The command “#pragma” is basically used for granting anew function to the preprocessor or for providing information dependenton implement to the compiler. In the C+ATL source program createdaccording to the embodiment, a description in ATL, which is a specificlanguage, is embedded as a token given by “#pragma”. Processing of theATL description given by “#pragma” will be described later.

The contents of the description, which define processes such as the callof the ATL object file, and data process, in the row numbers 10 to 28 inthe C+ATL source program shown in FIG. 3 are same with the contentscreated on the workstation of the conventional semiconductor testingsystem.

After the completion of the creation of the C+ATL source program, theprogram developer designates a file of the created C+ATL source program(hereinafter referred to as a C+ATL source file including necessaryfiles such as a header file) to the integrative compiler 34 to executethe compile (at step S120). At the execution of the compile, the syntaxchecking is first performed and when the syntax error is found, theprogram developer corrects the error with the editor 28 and designatesthe execution of compile again. When no error is found, the compilingprocess for creating the object file starts.

FIG. 4 is a flowchart of the compiling process conducted by theintegrative compiler 34. When no syntax error is-found in the C+ATLsource file created at the step S110, the integrative compiler 34proceeds to extract the ATL description from the C+ATL source file tocreate the ATL source file (at step S121). FIG. 5 is shown to describethe process of ATL source file creation. The creation process of the ATLsource file, as described above, starts with the identification of“#pragma” from the preprocessor description in the C+ATL source file andthe analysis of a token following the “#pragma”. In an example shown inFIG. 5, “atl” immediately after “#pragma” is a keyword which indicatesthat the following information is the ATL description.

More specifically, with reference to the example of FIG. 5, theintegrative compiler 34, upon recognizing “#pragma atl” in the rownumber 3, extract the following keyword “name”, thereby interpretingthat the description marked with a double quotation mark following thekeyword “name”, i.e., “SAMPLE”, is a program name. According to theinterpretation, “PRO SAMPLE” is inserted at the beginning of the ATLsource file. Then, the integrative compiler 34, recognizing “#pragmaatl” in the row number 4, extracts the following keyword “socket” andinterprets that the description marked with a double quotation markfollowing the keyword “socket”, i.e., “SSOC” is a socket program name ofthe ATL. According to the interpretation, “SSOC” is inserted after “PROSAMPLE” in the ATL source file. Then, the integrative compiler 34,recognizing “#pragma atl” in the row number 5, extracts the followingkeyword “proc” and interprets that the character sequence immediatelyafter the keyword “proc” and the following description marked with adouble quotation mark, i.e., “P1 (ARG1, ARG2(2)) “{WRITE “ARG1=”,ARG1,/WRITE “ARG2=”, ARG2,/}”, as a function definition. According tothe interpretation, the description

-   P1:ARGUMENT (ARG1, ARG2(2))    -   WRITE “ARG1=”, ARG1,/    -   WRITE “ARG2=”, ARG2,/    -   GOTO CONTINUE        is added to the ATL source file.

Then, the integrative compiler 34, upon reaching the last row number(row number 28) of the C+ATL source file without finding any more“#pragma atl” in the C+ATL source file, inserts “END” in the tail of theATL source file to finish the creation of the ATL source file.

After the completion of the ATL source file creation, the integrativecompiler 34 conducts a compiling of C language description in the C+ATLsource file, i.e., a creation of C object code (at step S122). Theordinary C compiler (corresponding to the general-purpose languagecompiler 29) conducts the compile, ignoring the description of “#pragma”described above. In the embodiment the integrative compiler 34 calls theC compiler for the process, however, the function of the C compiler maybe embedded into the integrative compiler 34 itself to perform the Cobject code creation in parallel with the ATL source file creationdescribed above. Then, the general-purpose language compiler 29 shown inFIG. 1 may be unnecessary.

After the completion of the C object code creation, the integrativecompiler 34 conducts a compile of the ATL source file created at stepS121, i.e., the creation of the ATL object code (at step S123). With thecall of the ATL compiler (corresponding to the specific languagecompiler 30), the compile is executed. Similar to step S402 of FIG. 12,the file is translated into a machine language specific to the oldtester processor (machine language comprehensible in a specific testerprocessor) which is different from a machine language described in the Cobject code.

After the completion of the creation of the ATL object code, theintegrative compiler 34 combines the C object code created at step S122with the ATL object code created at step S121 and adds positioninformation of a location where the ATL object code is stored (ATLobject code starting point), to create an object file (hereinafterreferred to as “C+ATL object file”) (at step S124). FIG. 6 shows astructure of such C+ATL object file. As shown in FIG. 6, in the C+ATLobject file, the ATL object code is arranged after the C object code. InFIG. 6, additional information such as the position information of theATL object code is now shown.

The integrative compiler 34 conducts the compiling process on the C+ATLsource files created in the same manner, thereby preparing a pluralityof C+ATL object files. After the compiling process by the integrativecompiler 34, the program developer designates to the linker 33 necessarylibrary files for the plurality of C+ATL object files created asdescribed above and the like, to execute linking (step S130 of FIG. 2).

The linker 33, in addition to the necessary library files for theplurality of C+ATL object files created as described above and the like,prepares and links a load program for loading the ATL object codesection from each of the C+ATL object files to create a single objectfile directly executable on the tester processor of the semiconductortest equipment 11.

When the single object file is ready after the procedure as describedabove, the program developer starts up a control program that enablesthe communication with the semiconductor test equipment 11 on theworkstation 10 to transfer the single object file to the testerprocessor of the semiconductor test equipment 11 using the controlprogram (at step S140).

Then, the program developer gives an execution direction of the singleobject file to the control program (at step S150). In response to thedirection, the tester processor of the semiconductor test equipment 11first loads the C object cod and the ATL object code arranged in thesingle object file on the memory according to the load program includedin the single object file. The tester processor then repeats the processof: an execution of the loaded ATL object code; an operation of adesired testing unit in the main tester unit; an acquisition of testresults from the tested device; and data processing, according to thealgorithm described in the loaded C object code. Here, the test result,after appropriate data processing, may be received by the controlprogram mentioned above via the communication interface of thesemiconductor test equipment 11, the communication cable, and thecommunication interface 41 of the workstation 10, and displayed on awindow screen allocated to the control program similarly to theconventional technique.

Though the load program is assumed to be included in the single objectfile here, the load program may be previously read out and stored in thetester processor of the semiconductor test equipment 11 and started upat the beginning of the process according to the execution directionfrom the workstation 10.

Next, the debugging process of the semiconductor testing systemaccording to the embodiment will be described. The program developer,when inconveniences such as the abnormality are found from the testresult obtained through the execution of step S150, performs thedebugging process on the device test program as in the conventionaltechnique. First, the program developer starts up the integrativedebugger 35 on the workstation 10 to set a breakpoint in a predeterminedstatement in the C+ATL source file.

Then, in response to the direction to start debugging sent from theprogram developer, the integrative debugger 35 executes the singleobject file according to the procedure of steps S120 to S150 describedabove. Upon detection that the processing reaches the breakpoint in theexecuted statement, the integrative debugger 35 executes a debuggerselecting routine to select which of a C debugger (corresponding to thegeneral-purpose language debugger 31) or an ATL debugger (correspondingto the specific language debugger 32) is to be started up.

FIG. 7 is a flowchart of the debugger selecting routine. The integrativedebugger 35, when the process reaches the breakpoint of the statementsequentially executed in the single object file, displays the statementin which the breakpoint is set (at step S201). Then, when the statementis in the ATL object code section (Yes in step S202), the integrativedebugger 35 starts up the ATL debugger (at step S206) to-acquire debuginformation such as a variables included in the statement withbreakpoint from the ATL debugger (at step S207). Here, when thebreakpoint is set as mentioned above, the ATL debugger acquiresbreakpoint setting information of the ATL object code section via theintegrative debugger.

The integrative debugger 35, upon acquiring the debug information fromthe ATL debugger, displays a designated variable (symbol) which isrendered effective at the time of break (at step S205). FIG. 8 shows anexample of an execution screen of the integrative debugger 35,particularly in a condition where the break is occurred in the ATLdescription. In FIG. 8, the integrative debugger 35, in addition to astandard window display setting as title bar and a menu bar in anexecution window 50, displays a breakpoint setting area 51, a sourcedisplay area 52, and a symbol display area 53. In FIG. 8, to indicatethe break state of the ATL description in the C+ATL source program, thestatement with the row number 5 where the breakpoint is set is shown inthe source display area 52, and variables and values the variables inthe statement can take are shown in the symbol display area 53.

On the other hand, the integrative debugger 35, when the statement witha break is in the C object code section (No at Step S202), starts up theC debugger (at step S203) to acquire debug information such as avariable included in the statement with break from the C debugger (atstep S204). Here, the C debugger, at the time of breakpoint setting,acquires the breakpoint setting information of the C object code sectionvia the integrative debugger 35.

The integrative debugger 35, upon acquiring the debug information fromthe C debugger, displays a designated variable (symbol) which isrendered effective at the break (at step S205). FIG. 9 shows an exampleof an execution screen of the integrative debugger 35, particularly in astate where the break is occurred in the C language description. Theexecution window 50 of the integrative debugger 35 shown in FIG. 9 is ofsimilar configuration with the window shown in FIG. 8. In FIG. 9, toindicate the state where the break is occurred in the C languagedescription of the C+ATL source program, the statement with the rownumber 15 with the breakpoint is shown in the source display area 52 anda variable and a value the variable in the statement can take aredisplayed in the symbol display area 53.

The program developer, upon finding a logical error through checking ofthe variable displayed on the window screen of the integrative debugger35, starts up the editor 28 to correct the C+ATL source file asnecessary and to repeat the procedure of steps S120 to S150.

As described above, the semiconductor testing system according to theembodiment, i.e., the program development supporting apparatus, theprogram executing apparatus, the compiling method and the debuggingmethod according to the present invention, through the embedding of theATL source which is the specific language program into the C languagesource which is the general-purpose language program, allows thehandling of two different sources, which are conventionally managedseparately, as one C+ATL source file, whereby the file management issimplified and the efficiency of program development is enhanced.

In the embodiment, the workstation and the semiconductor test equipmentare employed as examples of the program development supporting apparatusand the program executing apparatus according to the present invention.It is clear, however, that general-purpose computer system and devicessuch as measuring device or a control device communicative with thecomputer system can be employed as the program development supportingapparatus and the program executing apparatus.

As described above, the program development supporting apparatus, theprogram executing apparatus, the compiling method and the debuggingmethod according to the present invention, through the embedding of thespecific language program itself into the general-purpose languageprogram, allows the handling of the different source programs which areconventionally managed separately as one file not only at the stage ofthe source file but also at the stage of the object file created throughcompiling, whereby the file management is simplified and the efficiencyof program development is improved.

INDUSTRIAL APPLICABILITY

As can be seen from the foregoing, the program development supportingapparatus, the program executing apparatus, the compiling method and thedebugging method according to the present invention is useful forefficient development of the high-performance program (firmware) forelectronic devices and simplification of program management, and inparticular is suitable for the development and the management ofprograms for semiconductor test equipments.

1. A program development supporting apparatus for generating a programfile executable on a predetermined program executing apparatus from amixed language source program where a specific language source programis described in a predetermined area of a general-purpose sourceprogram, comprising: a specific language compiling unit that compilesthe specific language source program to create a specific languageobject code; a general-purpose language compiling unit that compiles thegeneral-purpose language source program of the mixed language sourceprogram to create a general-purpose language object code; an integratedcompiling unit that extracts the specific language source program fromthe mixed language source program, makes the specific language compilingunit execute by designating the extracted specific language source,makes the general-purpose language compiling unit execute by designatingthe mixed language source program, and integrates the obtained specificlanguage object code and the general-purpose language object code tocreate an object file; and a linking unit that creates the program filefrom at least one object file created by the integrated compiling unit.2. The program development supporting apparatus according to claim 1,wherein the integrated compiling unit adds code position information ofat least one of the specific language object code and thegeneral-purpose language object code.
 3. The program developmentsupporting apparatus according to claim 1, further comprising a programtransferring unit that transfers the program file to the programexecuting apparatus.
 4. The program development supporting apparatusaccording to claim 3, further comprising a program executing apparatuscontrolling unit that gives an instruction to the program executingapparatus to execute the program file transferred to the programexecuting apparatus.
 5. The program development supporting apparatusaccording to claim 1, further comprising a breakpoint setting unit thatsets a breakpoint in a statement in the mixed language source program,wherein the execution of the program file is stopped at the breakpointduring the execution, a general-purpose language debugger is started upwhen the statement of the stopped program file belongs to thegeneral-purpose language source program, and a specific languagedebugger is started up when the statement of the stopped program filebelongs to the specific language source program.
 6. The programdevelopment supporting apparatus according to claim 5, wherein debuginformation obtained from the general-purpose language debugger and thespecific language debugger are displayed on a common window screen. 7.The program development supporting device according to claim 1, whereinthe general-purpose language is C language and the specific languagesource program is described in the general-purpose language sourceprogram by a preprocessor command in the general-purpose language sourceprogram.
 8. The program development supporting apparatus according toclaim 7, wherein the preprocessor command is “#pragma”.
 9. The programdevelopment supporting apparatus according to claim 1, wherein theprogram executing apparatus is a semiconductor test equipment.
 10. Aprogram executing apparatus that executes a program file where an objectcode of a general-purpose language source program and an object code ofa specific language source program are present in a mixed manner,wherein the object code of the general-purpose language source programand the object code of the specific language source program are loadedon a memory when an execution of the program file starts.
 11. Theprogram executing apparatus according to claim 10, wherein the programexecuting apparatus is a semiconductor test equipment.
 12. A compilingmethod for generating a program file executable on a predeterminedprogram executing apparatus from a mixed language source program where aspecific language source program is described in a predetermined area ofa general-purpose language source program, comprising: a specificlanguage source program extraction step of extracting the specificlanguage source program from the mixed language source program; aspecific language compiling step of compiling the extracted specificlanguage source program to create a specific language object code; ageneral-purpose language compiling step of compiling a description ofthe general-purpose language source program of the mixed language sourceprogram to create a general-purpose language object code; an object filecreation step of combining the specific language object code and thegeneral-purpose language object code to create an object file; and alinking step of creating the program file from at least one object filecreated by the object file creation.
 13. A debugging method fordebugging a program file executable on a predetermined program executingapparatus created from a mixed language source program where a specificlanguage source program is described in a predetermined area of ageneral-purpose language source program, comprising: a breakpointsetting step of setting a breakpoint in a statement in the mixedlanguage source program; a debugger starting up step of stopping theprogram file at the breakpoint during execution of the program file,starting up a general-purpose language debugger when the statement ofthe stopped program file belongs to the general-purpose language sourceprogram, and starting up a specific language debugger when the statementof the stopped program file belongs to the specific language sourceprogram; and a debug information display step of displaying-debuginformation obtained from the general-purpose language debugger and thespecific language debugger on a common window screen.
 14. A computerreadable recording medium that records a program that makes a computerexecute steps to create a program file executable on a predeterminedprogram executing apparatus from a mixed language source program where aspecific source program is described in a predetermined area of ageneral-purpose language source program, the steps comprising: aspecific source program extraction step of extracting the specificlanguage source program from the mixed language source program; aspecific language compiling step of compiling the extracted specificlanguage source program to create a specific language object code; ageneral-purpose language compiling step of compiling a description ofthe general-purpose language source program from the mixed languagesource program to create a general-language object code; an object filecreation step of combining the specific language object code and thegeneral-purpose language object code to create an object file; and alinking step of creating the program file from at least one object filecreated by the object file creation.
 15. A computer readable recordingmedium that records a program that makes a compute execute steps todebug a program file executable on a predetermined program executingapparatus created from a mixed language source program where a specificlanguage source program is described in a predetermined area of ageneral-purpose language source program, the steps comprising: abreakpoint setting step of setting a breakpoint in a statement in themixed language source program; a debugger starting up step of stoppingthe program file at the breakpoint during execution of the program file,starting up a general-purpose language debugger when the statement ofthe stopped program file belongs to the general-purpose language sourceprogram, and starting up a specific language debugger when the statementof the stopped program file belongs to the specific language sourceprogram; and a debug information display step of displaying debuginformation obtained-from the general-purpose language debugger and thespecific language debugger on a common window screen.